Description

Problem*

Resolves #3809

Summary*

This PR modifies the algorithm for how we map the debug information when we optimize/transform the circuit such that it scales linearly with the number of opcodes rather than quadratically.

Previously we would:

• Take an old opcode location
  • Search the entire new circuit for opcodes which were mapped from that opcode
  • Apply the debug information to each new opcode.
• repeat until no more opcode locations exist.

This then has to search through the entire list of opcodes once per opcode. We know that optimisation/transformation doesn't reorder opcodes so a lot of this work is unnecessary, we can instead build up a reverse mapping in a single pass and then just use that.

I've changed the debug info transformation process to build a mapping from an old opcode location to the set of corresponding new opcode locations once, we can then just iterate through all of the opcode locations and map them to the new opcode locations.

There's still some issues in this code. We were (and still are) treating all opcodes with the same ACIR index as coming from the same location. This likely means we're either: a) not mapping brillig opcodes correctly or b) unnecessarily mapping brillig opcodes multiple times. I'm not too bothered about this for this PR as the behaviour is unchanged and it's more important to get the speed increase on master rather than chase potential improvements.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.